在Kubernetes集群上自主运行的Pod对象在非计划内终止后，其生命周期即告结束，用户需要再次手动创建类似的Pod对象才能确保其容器中的依然可得。对于Pod数量众多的场景，尤其是对微服务业务来说，用户必将疲于应付此类需求。Kubernetes的工作负载（workload）类型的控制器能够自动确保由其管控的Pod对象按用户期望的方式运行，因此，Pod的创建和管理大多会通过这种类型的控制器来进行，包括Deployment、ReplicasSet、ReplicationController等。

1）创建Deployment控制器对象

kubectl run命令可用于命令行直接创建Deployment控制器，并以 --image选项指定的镜像运行Pod中的容器，--dry-run选项可以用于命令的测试，但并不真正执行资源对象的创建过程。

2）打印资源对象的相关信息

kubectl get 命令可用来获取各种资源对象的相关信息，它既能显示对象类型特有格式的简要信息，也能按照指定格式为YAML或JSON的详细信息，或者使用Go模板自定义要显示的属性及信息等。

3）访问Pod对象

这里部署的是pod是运行的为nginx程序，所以我们可以访问是否ok，在kubernetes集群中的任意一个节点上都可以直接访问Pod的IP地址。

If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.

For online documentation and support please refer tonginx.org.Commercial support is available atnginx.com.

Thank you for using nginx.[root@k8s-node2 ~]# curl 10.244.1.12 #kubernetes集群的node节点上访问DOCTYPE html>Welcome to nginx! body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; }Welcome to nginx!

If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.

For online documentation and support please refer tonginx.org.Commercial support is available atnginx.com.

Thank you for using nginx.

上面访问是基于一个pod的情况下，但是，当这个pod由于某种原因意外挂掉了，或者所在的节点挂掉了，那么deployment控制器会立即创建一个新的pod，这时候再去访问这个IP就访问不到了，而我们不可能每次去到节点上看到IP再进行访问。测试如下：

If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.

For online documentation and support please refer tonginx.org.Commercial support is available atnginx.com.

Thank you for using nginx.

简单来说，一个Service对象可视作通过其标签选择器过滤出的一组Pod对象，并能够为此组Pod对象监听的套接字提供端口代理及调度服务。就好比上面做的测试，如果没有Service，那么每次都得去访问pod对象自己的地址等。且那还只是创建了一个pod对象，如果是多个。那么该如何是好？故使用Service解决此问题。

1）创建Service对象(将Service端口代理至Pod端口示例)

"kubectl expose"命令可用于创建Service对象以将应用程序“暴露”（expose）于网络中。

这时候可以在kubernetes集群上所有节点上直接访问nginx-svc的cluster-ip及可访问到名为deployment控制器下nginx的pod。并且，集群中的别的新建的pod都可以直接访问这个IP或者这个service名称即可访问到名为deployment控制器下nginx的pod。示例：

If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.

For online documentation and support please refer tonginx.org.Commercial support is available atnginx.com.

Thank you for using nginx.#新建一个客户端pod进行访问，这里这个客户端使用busybox镜像，且pod副本数量为1个，-it表示进入终端模式。--restart=Never，表示从不重启。[root@k8s-master ~]# kubectl run client --image=busybox --replicas=1 -it --restart=NeverIf you don't see a command prompt, try pressing enter./ # wget -O - -q 10.109.54.136 #访问上面创建的（service）nginx-svc的IPWelcome to nginx!....../ # / # wget -O - -q nginx-svc #访问上面创建的（service）名称nginx-svcWelcome to nginx!

2）创建Service对象(将创建的Pod对象使用“NodePort”类型的服务暴露到集群外部)

客户端访问kubernetes集群的30884端口

3）Service资源对象的描述

“kuberctl describe services”命令用于打印Service对象的详细信息，它通常包括Service对象的Cluster IP，关联Pod对象使用的标签选择器及关联到的Pod资源的端点等。示例

所谓的“伸缩（Scaling）”就是指改变特定控制器上Pod副本数量的操作，“扩容（scaling up）”即为增加副本数量，而“缩容（scaling down）”则指缩减副本数量。不过，不论是扩容还是缩容，其数量都需要由用户明确给出。

Service对象内建的负载均衡机制可在其后端副本数量不止一个时自动进行流量分发，它还会自动监控关联到的Pod的健康状态，以确保将请求流量分发至可用的后端Pod对象。若某Deployment控制器管理包含多个Pod实例，则必要时用户还可以为其使用“滚动更新”机制将其容器镜像升级到新的版本或变更那些支持动态修改的Pod属性。

使用kubect run命令创建Deployment对象时，“--replicas=”选项能够指定由该对象创建或管理的Pod对象副本的数量，且其数量支持运行时进行修改，并立即生效。“kubectl scale”命令就是专用于变动控制器应用规模的命令，它支持对Deployment资源对象的扩容和缩容操作。

上面示例中创建的Deployment对象nginx仅创建了一个Pod对象，其所能够承载的访问请求数量即受限于这单个Pod对象的服务容量。请求流量上升到接近或超出其容量之前，可以通过kubernetes的“扩容机制”来扩招Pod的副本数量，从而提升其服务容量。

扩容示例

缩容示例

缩容的方式和扩容相似，只不过是将Pod副本的数量调至比原来小的数字即可。例如将nginx的pod副本缩减至2个

有一些不再有价值的活动对象可使用“kubectl delete”命令予以删除，需要删除Service对象nginx-svc时，即可使用下面命令完成：

有时候要清空某一类型下的所有对象，只需要将上面的命令对象的名称缓存“--all”选项便能实现。例如，删除默认名称空间中所有的Deployment控制器的命令如下：

注意：受控于控制器的Pod对象在删除后会被重建，删除此类对象需要直接删除其控制器对象。不过，删除控制器时若不想删除其Pod对象，可在删除命令上使用“--cascade=false“选项。

虽然直接命令式管理的相关功能强大且适合用于操纵Kubernetes资源对象，但其明显的缺点是缺乏操作行为以及待运行对象的可信源。另外，直接命令式管理资源对象存在较大的局限性，它们在设置资源对象属性方面提供的配置能力相当有限，而且还有不少资源并不支持命令操作进行创建，例如，用户无法创建带有多个容器的Pod对象，也无法为Pod对象创建存储卷。因此，管理资源对象更有效的方式是基于保存有对象配置信息的配置清单来进行。